…equal`

Follows #1704.

== Exclude ==

Exclude Map/Set tests from the comparison because, unlike QUnit,
fast-deep-equal does not perform a deep equal but a shallow strict
equal when it comes to Map and Set.

```js
const QUnit = require('qunit');
const fde = require('fast-deep-equal/es6');

a = new Set([ { x: 1 }, { y: 2 } ]);
b = new Set([ { x: 1 }, { y: 2 } ]);
QUnit.equiv(a, b); // true
fde(a, b); // false
```

== Local alias ==

Assign local `equiv` in the bench.js file. Without this, even when a
dummy implementation like `QUnit.equiv = (a, b) { return a === b; }`
was still reported as 3X slower than fast-deep-equal holding the
identical function.

```
require('fast-deep-equal/es6').toString().slice(0, 100);
//> 'function equal(a, b) { if (a === b) return true; // …'

require('qunit').equiv+'';
//> 'function equiv(a, b) { if (a === b) return true; // …'
```

For example (with the above fake implementation):

```
fast-deep-equal (primitives) x 648,076 ops/sec ±0.27% (89 runs sampled)
QUnit.innerEquiv (primitives) x 255,011 ops/sec ±0.22% (90 runs sampled)
```

I eventually figured out this is because without the alias, our
benchmark case has to resolve "QUnit" of `QUnit.equiv` through every
lexical scope up to the global sope, and then access the (theoretically
mutable) "equiv" property, and so this every time. For very sensitive
workloads (like the "QUnit.equiv primitives" fixture), which basically
just hit the first `a === b` condition and return early, this is visible
in the benchmark results.